Historically, packet-based processing has been implemented by applying one of two models, including a packet-based datapath model and a flow-based datapath model. In a flow-based datapath model, data that is searched, retrieved, or calculated during processing of the first packet of the flow is cached for reuse during processing of subsequent packets of the same flow. A flow table is built and maintained at each host and each flow table entry corresponds to and includes essential identifying and switching information concerning the flow. Entries are added to the flow table either during the processing of the first packet of the flow appearing at the flow-based datapath or in response to a control plane command issued prior to the first packet being encountered. When a packet is received at a node, if the packet is associated with a flow table entry, the entry is retrieved from memory and used to grant the packet the required services with minimal additional memory access.
In a flow-based datapath model, such as OpenFlow, for example, the flow table in the datapath, or fast path, is programmed as a result of the action taken for the same flow in the slow path. For example, in a digital virtual switch (“DVS”), such as Nexus 1000V, available from Cisco Systems, Inc., of San Jose, Calif., a packet is sent to the slow path for further processing if there is a “flow miss” (i.e., there is no flow table entry for the flow) in the fast path. Once the packet is processed by the slow path, a corresponding flow is programmed in the fast path with the switching decision by adding an entry to the flow table. Entries remain in the flow table until they are removed, or “aged out,” for one of a variety of reasons. Understandably, using this model, flow table space, or “flow space,” is a critical resource. If the space is not used efficiently, the result will be increased look-up times or packets being relegated to the slow path.